home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Amiga Collections: MegaDisc
/
MegaDisc 06 (1988)(MegaDisc Digital Publishing)(AU)[m][WB].zip
/
MegaDisc 06 (1988)(MegaDisc Digital Publishing)(AU)[m][WB].adf
/
ARTICLES
/
CommProtocols
< prev
next >
Wrap
Text File
|
1988-03-28
|
6KB
|
129 lines
File Transfer Protocols.
************************
ED. NOTE: This is a good coverage of the various Communications
protocols available, by the sysop of Sydney's best bbs, where you'll
find lots of files, and a Megadisc section for uploading and
downloading Megadisc files. Tel: (02) 5216338.
A file transfer Protocol is like a language used to agree on how a file
should be transferred. The nice part about transfer protocols is that they
work regardless of the types of computers involved. File transfer protocols
send data in what is know as blocks. That is, the file is sent to the other
system one block at a time. Each block is checked for integrity and if an
error is detected, the receiving system requests the host system to resend
the block.
As long as both systems agree on the SAME file transfer protocol, most
transfers are error free and extremely simple to initiate.
The following list are the most common file transfer protocols and each one
will be discussed in detail. The protocols are listed in rough order of
their accuracy (error detection) and transfer speed.
Ascii Text
Kermit
X-Modem
X-Modem-CRC
Y-Modem-Batch
Y-Modem
Z-Modem
If your telecommunications program supports Y-Modem or Z-Modem then use one
of these as they are both the most reliable and fastest.
With the exception of Ascii Text, all other protocols use some form of error
checking. Error-checking is a feature whereby the file transfer protocol
tries to monitor the transfer and compensate for poor quality or surplus line
noise which can scramble data. When an error is detected, the receiving
system prompts the host to resend that block.
Protocols In Profile
********************
ASCII TEXT: This is a very basic file transfer Protocol. When a binary file
is sent, it is converted into it's Hexadecimal values and displayed on the
screen. This is the only protocol where you acually see the data being
transferred. No error checking is supported! Before you use this protocol
to download a file, open a capture buffer and make sure it is closed, That
is, the capture buffer is available to store data to disk, but the actual
buffer is closed to prevent unwanted data from entering the buffer. When you
download a file using this protocol the host usually sends a decimal 18
command which most telecommunications programs recognise as a signal to open
the capture buffer to store the HEX display, when the transfer is complete
the host sends a decimal 20 which closes the capture buffer. This way,
unwanted data is prevented from entering the Hex coded download file. The
receiving telecommunications program should have a facility to convert the
HEX code back to an executeable program. If the file is a text file then the
buffer is opened as above but not converted to HEX.
KERMIT: This has been the standard protocol used by Mainframe systems for
many years. If you use this protocol, setting your stop bits to 1, word
length to 7 and Even Parity will increase the transfer time two-fold for
binary files, you are advised to use a stop bit of 1, word length of 8 and No
Parity.
Kermit automatically sends the filename along with the filesize. The
receiving system need only select file receive and the host and Kermit
handle the rest.
X-Modem: This is the protocol originally written by Ward Christensen and in
use by almost every type of computer.
It is the same as X-Modem-CRC, only it uses Checksum error correction instead
of CRC, which is not as reliable.
X-Modem-CRC: This has long been a standard with its outstanding error
detection. It's biggest drawback is it transfers data in 128 byte blocks. as
with kermit 8N1 is used over 7E1 for time saving.
Y-Modem Batch: This is the same as Y-Modem, only the filesname is not entered
at the receiving end of the system. Y-Modem Batch sends the filoename along
with the filesize. The receiving system only selects file receive. When
uploading using Y-Modem Batch you are usually not prompted for a filename as
this is sent by the protocol.
Y-Modem: This is basically X-Modem-CRC with 1024 byte blocks. The advantage
is, more data sent per block. thus less blocks to error check which is
time consuming. The only problem is when line quality is poor, 128 byte
blocks take less time to resend.
Z-MODEM: Currently this is the fastest file transfer protocol in the public
domain. A file is normally sent in 1024 byte blocks. This value changes based
on system performance and is automatically handled by Z-Modem. The reason
for Z-Modem's outstanding performance is the way it detects errors. With
the exception of Ascii Text, the protocols listed send one block of
information at a time and wait for the remote system to receive it,
acknowledges the block and then sends the command to continue with the next
block. Z-Modem uses continuous data streaming, it doesn't wait for an OK from
the remote system before sending the next block. In effect Z-Modem ignores
the stop signals until an error is detected, the receiving system sends a
request to the host to re-send the data from where the error occurred. While
several kilobytes of data may belost due to the delay in receiving the error
message, the overall transfer rate is far superior and outweighs an
occassional bad block.
This Protocol proves useful when calling through a packet network. Packet
networks normally experience long delays using the traditional file transfer
protocols, since it takes several seconds before an acknowledgement is
received from the remote system. In the same time Z-Modem can send two or
more blocks of data.
Always make sure you initiate your file transfer protocol from the host end
FIRST, and then complete the transfer sequence at the receiving end. Your
telecommunications package should provide the necessary information to
transfer files.
NB:
X-Modem, Y-modem and Y-Modem-Batch will pad a file with extraneous
characters to make the file length a multiple of either 128 or 1024 bytes,
this usually makes the file unexecutable. A public domain file called FIXOBJ
is used to rid downloaded files of the extra padding and retsore them to
executable form.
Arc-ed files should not need this procedure to be performed.
Hope this helps
Ross Kellaway.
********